To meet client demands, computing environments should be scalable, available and manageable. Technologies referred to generally as “clustering” aim to address such concerns. A “cluster” may be defined as a group of independent computers that work together to run a common set of applications and that provide an image of a single system to a client and application. More generally, a cluster may be defined as a set of resources, made available to users and presented as a unified entity to the users.
While client users may not be aware that a cluster exists, they expect server-based resources (e.g., applications and data) to be readily available. With respect to availability, when a component or an application in a cluster fails, cluster software should respond, for example, by restarting the failed application or dispersing work from the failed component to another component in the cluster. Clustering technologies often provide a graphical console with tools, for example, to facilitate moving applications and data within the cluster to different servers. Such a clustering feature can be used, for example, to manually balance workloads and to unload servers for planned maintenance without downtime.
A clustering technology known as network load balancing (NLB) includes aspects of scalability, availability and manageability. NLB can be implemented in hardware (e.g., a dedicated NLB machine) or software (e.g., executing on hardware). NLB provides for strategic distribution of client requests or TCP/IP traffic to appropriate resources in a cluster. Some commercially available clustering technologies provide for NLB in a cluster of around 30 host servers. Some NLB techniques present a common “virtual” IP address for an entire cluster and transparently partition client requests across the multiple servers in the cluster.
One commonly used software NLB technique distributes incoming client requests for TCP and Universal Datagram Protocol (UDP) protocols, including HTTP, across multiple members of a cluster. In such a system, NLB software resides on each member of the cluster. Periodically, each member transmits an NLB exchange message over its network adapters. This message is used to coordinate actions between each member. By default, the period of message exchange is 1 second. As the state of the cluster changes (for example, by adding or removing members or setting members offline or online), the message exchanges for NLB are disrupted. After a certain number of failed message exchanges, NLB initiates a process to determine the current state of the cluster so that it can load balance the cluster properly. By default, NLB initiates this process after five failed message exchanges. NLB automatically redistributes requests among the active, remaining members. This redistribution ensures that non-active members do not receive any requests, and requests are only processed by active members.
In the foregoing software NLB example, each member in a cluster receives all incoming requests. This technique uses a fully distributed algorithm to determine which member processes the request; all other members discard the request. This method of load balancing may be more efficient than using traditional load balancing devices (i.e., hardware NLB), because filtering unwanted requests is faster than routing them. However, the overall scalability of the software load balancing may still be unsatisfactory because all members receive all requests.
With respect to hardware NLB, a conventional implementation typically includes a master and a slave that may serve over 100 servers hidden behind a virtual IP address where each server has a “real” IP address. These devices can become bottlenecks under some circumstances, which, in turn, can adversely impact user experience. Hardware NLB can be expensive and, at times, unreliable.
In the aforementioned existing techniques for NLB, clients are essentially blind participants. As described herein, various exemplary techniques allow for client-side load balancing.